Skip to main content

Networking Challenges

ChatGTP Thread https://chatgpt.com/share/67245c1c-b13c-800f-b76c-efac8948147f-

1. Basic Namespace Creation and Communication​

Goal: Create isolated network namespaces and establish basic communication.

  • Create two network namespaces (ns1 and ns2) and connect them with a virtual Ethernet (veth) pair.
  • Assign IP addresses in the same subnet (e.g., 10.0.0.1 and 10.0.0.2).
  • Test connectivity with ping from one namespace to the other.

Commands:

ip netns add ns1
ip netns add ns2

ip link add veth1 type veth peer name veth2
ip link set veth1 netns ns1
ip link set veth2 netns ns2

ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth1
ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth2

ip netns exec ns1 ip link set veth1 up
ip netns exec ns2 ip link set veth2 up
Tips:​
  • Play around IP ranges. What happens if you restrict the IP range to /32? Can you communicate? Why not?
    • Because we assigned a single IP - the IP range of 10.0.0.1/32 is 10.0.0.1~10.0.0.1
  • if you can't communicate, is there anyway to solve it?
    • we can use ip route to establish a routing mechanism for a wider ip range
    • ip netns exec ns1 ip route add 10.0.0.0/16 via 10.0.0.1 dev veth1
    • It needs to be configured in both sides. If one side is not configured for routing, it doesn't receive back

2. Routing Through a Third Namespace​

Goal: Set up a basic router namespace (router) between two other namespaces (ns1 and ns2).

  • Create three namespaces: ns1, ns2, and router.
  • Use veth pairs to connect ns1 to router and ns2 to router.
  • Configure IP forwarding in router to allow packets to pass through.
  • Add routes in ns1 and ns2 so they can reach each other via router.

Commands:

ip netns add router 
# Connect ns1 to router, and ns2 to router, using `veth` pairs as in Exercise 1.
# Enable IP forwarding in router:
ip netns exec router sysctl -w net.ipv4.ip_forward=1
# Set up routes in ns1 and ns2 to route traffic through the router.
Step by Step​
Solution & Tips​
  • The key-point here is how you configure subnets.
  • Subnets are important because each device inside a subnet is expected to be reached without a router.
  • I was assigning 10.0.0.0/24 for all ns1 and ns2 - which at the router level was very confusing because it could not decide which device it would route traffic from a certain IP range.
  • So If it received 10.0.0.1/24 - and it has 2 devices configured for 10.0.0.0/24 it doesnt know which one to route for.
  • A second take away point is: Gateway are IP's assigned to the peer veth. So if ns1 (device) is connected to the router - router is only aware of it's Gateway IP
  • So to make this work you need
    • ns1 to have a subnet like 10.0.0.1/24 - which ranges from 10.0.0.1~10.0.0.254
    • ns2 to have subnet like 10.0.1.0/24 - which ranges from 10.0.1.1~10.0.1.254
    • router to have assigned end-range IP's from each subnet ns1 and ns2 to be their gateways
    • To properly route traffic and let ns1 reach ns2 - you need to route all traffic from the target subnet - ns2 is 10.0.1.0/24 to ns1 gateway in the router - 10.0.0.254 (repeat the same at the ns2)
  • Ensure the namespaces have the DIRECT and LOCAL ip routing - which is defaulted whenever assigning IPs.
    • 10.0.0.0/24 scope link src 10.0.0.1 dev veth1 means this subnet is DIRECTLY RECHEABLE via veth1 interface and don't need any gateway
    • 10.0.0.0/24 via 10.0.0.1 dev veth1 is wrong because you are treating veth1 as Gateway
  • Remember when trying to make two namespaces reacheable ALWAYS make sure each ns knows how to route packets in ip route

ChatGPT conversations:

3. Configuring a Virtual NAT Gateway​

Goal: Simulate a NAT setup with a namespace acting as a gateway.

  • Use iptables in a gateway namespace to NAT outbound traffic for an isolated client namespace.
  • Set up IP forwarding and a default route in client to send traffic to gateway.
  • Verify that traffic from client to an external IP is masqueraded by gateway.

Challenge: Use tcpdump in gateway to observe NAT translation.

Step by Step​

  • Setup the same namespace and router config from #2
# create a veth to link router ns with host interfaces
ip link add internet-veth type veth peer name veth-router
# link one end to the router namespace
ip link set internet-veth netns router
ip netns exec router ip link set internet-veth up

# add initial range IP to router namespace
ip netns exec router ip addr add 192.168.1.1/24 dev internet-veth
# add end-range IP to eth that will talk to host eth0
ip addr add 192.168.1.254/24 dev veth-router


# The NAT config makes all traffic leaving via this interface to have the IP rewritten with the eth0 IP - if we sent our private IP, the gateway wouldn't know how to answer back to us.

# enable NAT in the host
ip netns exec router iptables -t nat -j MASQUERADE -o eth0 -A POSTROUTING

# enable NAT in the router
ip netns exec router iptables -t nat -j MASQUERADE -o internet-veth -A POSTROUTING

Take Away Points​

  • NAT configuration is crucial to make devices in private networks to reach the internet.
  • NAT configuration makes it possible for ISP Gateway respond back with packets since you masquerade the outgoing traffic IP with an IP they can trace you - and not with your private IP.
  • But why do I need NAT in both host and router?
    • Because the IP that would reach the host is unknown and not within any interfaces ip ranges that it knows.
    • So the router needs to translate the IP address to something the host will understand and know where to redirect it whenever the packet is coming back

ChatGPT conversation:

4. Bridging Multiple Namespaces on a Virtual Network​

Goal: Create a virtual switch using a bridge and connect multiple namespaces to it.

  • Set up a bridge (br0) in the root namespace.
  • Attach veth pairs from multiple namespaces (ns1, ns2, ns3) to the bridge.
  • Assign IP addresses in the same subnet, then test communication between all namespaces. Challenge: Try disconnecting one namespace and observe if the rest can still communicate.

Step by Step​

# set up namespace, create veth, assign it and turn it up
#for each namespace to create
NETNS={{netns_name}}
ip netns add $NETNS
ip link add veth_$NETNS type veth peer name veth-$NETNS-bridge
ip link set veth_$NETNS netns $NETNS
ip netns exec $NETNS ip link set veth_$NETNS up
# increment end-range
ip netns exec $NETNS ip add 10.100.0.2/24 dev veth_$NETNS

#create bridge device
ip link add br0 type bridge
ip link set br0 up
ip addr add 10.100.0.1/24 dev br0
# for each veth created - bind them to the bridge device
ip link set veth-$NETNS-bridge master br0
ip link set veth-$NETNS up

#verify with some target IP
ip netns exec veth_$NETNS ping 10.100.0.3/24

Takeaway Points​

  • bridges are virtual devices meant to connect interfaces with the Kernel
  • All devices within the bridge must share the same subnet

5. Isolated DNS Server in a Namespace​

Goal: Configure a namespace as a DNS server and point other namespaces to it.

  • Set up dnsmasq or a lightweight DNS server in dns-server namespace.
  • Configure other namespaces (ns1, ns2) to use dns-server for DNS resolution.
  • Add custom DNS entries and test resolution from ns1 and ns2.

Step by Step​

# set up ns and router configurations

#create namespace and configure it to connect to the router to be reacheable
ip netns add dns-server
ip link add dns-veth type veth peer name dns-gateway
ip link set dns-veth netns dns-server
ip netns exec dns-server ip link set dns-veth up
ip netns exec dns-server ip addr add 10.0.2.1/24 dev dns-veth #assign other subnet

ip link set dns-gateway netns router
ip netns exec router ip link set dns-gateway up
ip netns exec router ip addr add 10.0.2.254/24 dev dns-gateway

# ensure loopback it's up and running
ip netns exec dns-server ip route add 10.0.0.0/16 via 10.0.2.254

#ensure ns1 can ping dns-server IP and vice-verse
ip netns exec ns1 ping 10.0.2.1
ip netns exec dns-server ping 10.0.1.1

#configure dnsmasq
echo "
interface=dns-veth
bind-interfaces
server=8.8.8.8
listen-address=10.0.2.1
address=/my-server.com/10.100.0.1
" > dnsmasq.conf
ip netns exec dns-server dnsmasq --conf-file=/path/to/file

#ensure the server is working by forcing dig
ip netns exec dig @10.0.2.1 my-server.com

#dig within ns1
ip netns exec ns1 dig @10.0.2.1 my-server.com

#add value to resolve.conf in ns1 -- WARNING: This alter the host resolv.conf (is there any easier way?)
ip netns exec ns1 bash -c "echo nameserver 10.0.2.1 > /etc/resolv.conf"
ip netns exec ns1 dig my-server.com

#Can you resolve public DNS? Like google.com?

Takeway Points​

  • you can debug DNS servers using dig @<DNS_SERVER_IP>
  • I was having problem when assigning the IP address from the veth. Timing out when running the dig command. The main symptom was due to now being able to ping the veth IP itself from within the namespace. The root cause was loopback interface being down
  • Although PING is working, we need to configure networking rules/iptables for another types of packets like UDP/TCP for proper DNS resolution
  • DNS servers use TCP for ZoneTransfer and UDP for name resolution.
    • DNS uses TCP for Zone transfer and UDP for name, and queries either regular (primary) or reverse. UDP can be used to exchange small information whereas TCP must be used to exchange information larger than 512 bytes
  • tcpdump is useful to understand the routes from packets
    • is host receiving packets? is it routing correctly?
    • current config is routing everything right from router to host
    • by testing icmp vs tcp packets routing:
      • we could notice that HOST eth0 is not receivigin/routing any packets to public network
      • the packets stop at veth-host which is the peer from the router.
  • Remember to setup FORWARD reules in iptables AND check ufw
    • iptables -I FORWARD 6 -o veth-host -i eth0 -j ACCEPT
    • iptables -I FORWARD 6 -i veth-host -o eth0 -j ACCEPT
  • ICMP packets are often used for diagnostic so some firewalls just let it work. They behave very differently than TCP/UDP so it's always nice to check the FORWARDING rules for these packets

6. Simulate a VPN Gateway and Split-Tunneling​

Goal: Create a VPN-like namespace that routes specific traffic while allowing other traffic to bypass it.

  • Set up vpn-gateway namespace with IP forwarding and iptables rules for masquerading.
  • Configure client namespace to send specific IP ranges (like 10.0.0.0/24) through vpn-gateway while routing other traffic directly.

Challenge: Verify split-tunneling by testing access to IPs both inside and outside the specified range.

7. Packet Filtering with iptables​

Goal: Use iptables to filter traffic between namespaces.

  • Configure firewall namespace between two other namespaces (ns1, ns2).
  • Add iptables rules in firewall to allow only specific protocols (e.g., TCP on port 80).
  • Test connectivity for both allowed and blocked protocols.

Challenge: Set up logging to track dropped packets and analyze the logs.

8. Multi-Hop Routing with Multiple Routers​

Goal: Create a network with multiple hops between namespaces.

  • Set up three namespaces (ns1, router1, router2, and ns2) to simulate a network with multiple hops.
  • Configure routes and IP forwarding in each router so ns1 can communicate with ns2 through both router1 and router2.
  • Test connectivity and use traceroute to see the multi-hop path.

9. Simulate a Failover Route​

Goal: Set up two paths to a destination and simulate a failover when one path fails.

  • Create two paths from ns1 to ns2 via different routers (router1 and router2).
  • Configure ns1 with two default routes with different priorities, preferring one router over the other.
  • Test connectivity and simulate a failure by bringing down the primary router interface.

10. Load Balancing Traffic Between Namespaces​

Goal: Load-balance traffic between two destinations.

  • Set up two namespaces (server1 and server2) and configure a third namespace (load-balancer) to balance traffic between them.
  • Use iptables in load-balancer to round-robin or split traffic directed at a specific IP between server1 and server2.

Challenge: Use curl to send requests and observe how traffic is split across server1 and server2.

These exercises will give you practical exposure to essential networking concepts in a controlled, virtual environment. They should take you through increasingly complex scenarios, helping you gain confidence in setting up, troubleshooting, and managing networks using namespaces.